REMARKS 



Claims 21-30 have been amended. Claims 1-31 remain pending in the 
application. Reconsideration is respectfully requested in light of the following remarks. 

Section 101 Rejection : 

The Examiner rejected claims 21-30 under 35 U.S.C. § 101 as being directed to 
non-statutory subject matter. Applicants respectfully traverse this rejection. However, to 
further prosecution of the present application, claims 21-30 have been amended to recite 
a " computer-readable storage medium." Withdrawal of the § 101 rejection is respectfully 
requested. 

Section 102(e) Rejection ; 

The Examiner rejected claims 1-5, 7-15, 17-25 and 27-30 under 35 U.S.C. § 
102(e) as being anticipated by Beck et al. (U.S. Patent 6,604,140) (hereinafter "Beck"). 
Applicants respectfully traverse this rejection for at least the reasons presented below. 

Regarding claim 1, Beck fails to disclose a client reading an advertisement 
from a space , where the space comprises a network-addressable storage location, 
wherein the advertisement comprises a Uniform Resource Identifier (URI) and a 
schema, wherein the URI specifies a network address at which a service may be 
accessed, and wherein the schema specifies one or more messages usable to invoke 
one or more functions of the service. Beck teaches a service framework that enables 
devices to discover and use services over a network. Beck's service discovery is based 
on periodic multicasting of service descriptors. Beck teaches that an advertiser retrieves 
a service to advertise, creates a service descriptor and periodically broadcasts the 
descriptor (Beck, column 3, lines 59-64 and column 4, lines 40-50). 
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The Examiner cites, both in the rejection of claim 1 and in the Response to 
Arguments section of the Examiner's Answer, column 6, lines 1-16 where Beck describes 
how a client requests usage of a service by querying a service registry. However, Beck 
does not, either at the cited passage or elsewhere, mention a client reading an 
advertisement from a space. Instead, Beck teaches at the cited passage that a client 
furnishes a description of the requested service and that the registry matches this request 
against service descriptors of known services. If a service descriptor in the registry 
matches the description of the requested service, the registry verifies that the service is 
already loaded, and if not, loads the service. Beck does not teach that registry returns to 
the client (or that the client downloads) the service descriptor, which the Examiner 
contends is an advertisement. Instead, Beck teaches, "[t]he process of binding a service 
terminates in step 507 where a reference to the service adaptor is returned to the client" 
(emphasis added, Beck, column 6, lines 22-24). Elsewhere, Beck teaches that a service 
adaptor "provides an additional level of indirection between clients and the service" and 
that the service adaptor is a Java class (Beck, column 5, lines 55-61). 

In the Response to Arguments section of the Examiner's Answer, the Examiner 
also asserts that Beck's teachings regarding a service user receiving service descriptors 
multicast over the ad-hoc network by other device, without citing any particular portion 
of Beck. However, Beck teaches that it is the service user, not a client, that listens 
for and receives broadcast service descriptors and that the service user saves service 
descriptors in the registry which functions as described above to locate services for 
requesting clients. Furthermore, a service user receiving service descriptors that are 
broadcast over the network cannot be considered a client reading an advertisement from 
a space. 

The Examiner also asserts that the above "discussion of the service adaptor ... is 
irrelevant as it can be seen that Beck's client reads an advertisement from a space before 
downloading of the service interface, adaptor, and implementation." However, as noted 
above, the Examiner's interpretation of Beck is incorrect. Beck does not teach that a 
client reads an advertisement from a space before downloading a service adaptor, as the 
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Examiner asserts. Instead, as discussed above, Beck's client supplies a service 
description of a requested service and that the registry finds a matching service to load (if 
not already loaded). The client is then returned a reference to the service adaptor. 
Nowhere does Beck's client read an advertisement, as asserted by the Examiner. A client 
supplying a description of a requested client and, in return, receiving a reference to a 
service adaptor, does not disclose a client reading an advertisement from a space , as 
recited in Applicants' claim. 

Thus, a client in Beck's system requesting usage of service does not read an 
advertisement from a space, as suggested by the Examiner. Instead, as noted above, the 
client queries a service registry to obtain a reference to a service adaptor, which cannot be 
considered an advertisement as defined in claim 1. 

Further in regard to claim 1, Beck fails to disclose where the advertisement 
comprises a Uniform Resource Identifier (URI) and a schema , where the URI 
specifies a network address at which a service may be accessed, and where the 
schema specifies one or more messages usable to invoke one or more functions of the 
service. The Examiner cites column 4, lines 40-60 of Beck. However, the cited passage 
does not describe an advertisement that includes a schema that specifies messages usable 
to invoke functions of a service. Beck teaches that a "service descriptor contains 
information about the service, including the service name and a description of its 
function." Beck also states that an "enhanced service descriptor is a service descriptor 
that also contains the location of the code implementing the service." (Beck, column 4, 
lines 45-50). Beck does not describe a service descriptor as including a schema 
specifying messages usable to invoke functions of the service. Instead, Beck teaches that 
a client uses a Java interface for a service to call the methods that the service provides 
(Beck, column 5, lines 42-46 and column 6, lines 29-36). Beck specifically teaches that a 
client calls a method provided by the service's interface. Thus, not only does Beck fail to 
disclose an advertisement that includes a schema specifying messages usable to invoke 
functions of the service, Beck describes a Java interface for the service that a "defines the 
set of operations that the service can perform on behalf of a client" (Beck, column 5, lines 
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42-43). The service descriptor, which the Examiner equates to the advertisement of 
Applicants' claim, clearly does not include a schema specifying messages usable to 
invoke functions of a service. Moreover, as noted above, Beck's service descriptor 
cannot be equated to the advertisement of claim 1 because it is not read by a client from a 
space, as is explicitly stated in Beck. 

In the Response to Arguments section of the Examiner's Answer, the Examiner 
again cites column 4, lines 40-60 of Beck and asserts that Beck's "service descriptor 
clearly includes code to allow data transfer between the client and service which 
effectuates download of service functionalities and thus is ' usable to invoke one or more 
functions of the service'". Thus, the Examiner's argument appears to be Beck's invoking 
of service functions somehow discloses the specific limitation of claim 1 . However, as 
noted above, Beck teaches the user of Java Interface that "defines the set of operations 
that the service can perform". Also as noted above, Beck's Java Interface is clearly code 
and not part of the service descriptor, which the Examiner equates to the advertisement of 
Applicants' claim. Thus, Beck fails to disclose an advertisement that includes a schema 
specifying messages usable to invoke functions of the service. 

The Examiner also contends that since Beck's service descriptor "leads to the 
downloading of [the Java] interface, the service descriptor contains code for data 
transport that is 'usable to invoke one or more functions of the service'". Thus, the 
Examiner's argument appears to be that since Beck's service descriptor is somehow 
associated with the service interface, that the service descriptor must also include a 
schema specifying messages usable to invoke functions of the service. However, as 
discussed above, Beck teaches that a "service descriptor contains information about the 
service, including the service name and a description of its function." Beck also states 
that an "enhanced service descriptor is a service descriptor that also contains the location 
of the code implementing the service." Beck fails to mention anything about the 
service descriptor including a schema specifying messages, and the Examiner's 
contention that since service descriptor "leads to the downloading" of a Java 
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interface for the service, the service descriptor "contains code for data transfer" is 
clearly incorrect. 

Anticipation requires the presence in a single prior art reference disclosure of each 
and every limitation of the claimed invention, arranged as in the claim . M.P.E.P 2131; 
Lindemann Maschinenfabrik GmbH v. American Hoist & Derrick Co., 221 USPQ 481, 
485 (Fed. Cir. 1984). The identical invention must be shown in as complete detail as is 
contained in the claims. Richardson v. Suzuki Motor Co., 9 USPQ2d 1913, 1920 (Fed. 
Cir. 1989). As discussed above, Beck clearly fails to disclose a client reading an 
advertisement from a space , wherein the space comprises a network-addressable storage 
location, wherein the advertisement comprises a Uniform Resource Identifier (URI) and a 
schema , wherein the URI specifies a network address at which a service may be accessed, 
and wherein the schema specifies one or more messages usable to invoke one or more 
functions of the service . Therefore, Beck cannot possibly be said to anticipate claim 1. 
The rejection of claim 1 is not supported by the cited art, and removal thereof is 
respectfully requested. Similar remarks also apply to claims 1 1 and 21. 

Regarding claim 4, Beck fails to disclose wherein the schema is expressed in a 
data representation language. The Examiner cites column 5, lines 46-50. However, 
the cited portion of Beck teaches that a service interface 402 defines the set of operations 
that the service can perform on behalf of a client and that the service interface is a Java 
interface. As is well known in the art, a Java interface is not a schema expressed in a 
data representation language. Nowhere does Beck mention any schema expressed in a 
data representation language and clearly fails to disclose a schema expressed in a data 
representation language that is included in an advertisement. Without some teaching of 
Beck regarding a schema expressed in a data representation language, Beck cannot be 
said to anticipate claim 4. 

The Examiner, in the Response to Arguments section of the Examiner's Answer, 
contends that Applicant, "has failed to provide any basis for [the] conjecture" that a Java 
Interface is not a schema expressed in a data representation language. However, it is the 
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Examiner who shoulders the burden of proof, not the Applicants. The Examiner also 
asserts that a "data representation language is not further defined or explained in the 
claims so as to be distinguished over the Java programming language" and that "Java 
abstracts the data on bytecodes so what when applications are developed the same code 
may run in different environments." However, the Examiner's statements actually 
support Applicants 5 arguments. Java utilized bytecodes, which, by definition, cannot in 
any way be considered a data representation language. As is well understood by anyone 
of ordinary skill in the art, a data representation language is a particular type of language 
used to describe or represent data or content. No one of ordinary skill in the art would 
consider Java to be a data representation language. 

In response to the Examiner's argument that Applicant has not provided any basis 
for the fact that a Java interface is not a schema expressed in a data representation 
language, Applicant submits that it is the Examiner's obligation to "make clear that the 
missing descriptive matter is necessarily present in the thing described in the reference, 
and that it would be so recognized by persons of ordinary skill" (emphasis added). As 
described in the M.P.E.P at 2131.01 (III), "[t]o serve as an anticipation when the 
reference is silent about the asserted inherence characteristic, such gap in the reference 
may be filled with recourse to extrinsic evidence." In the present rejection, the Examiner 
merely cites column 5, lines 46-50 that does not include any mention of a schema 
expressed in a data representation language. Instead, the cited passage merely describes a 
Java Interface. The Examiner has not provided any extrinsic evidence that Beck's Java 
Interface necessarily includes a schema expressed in a data representation language . 
Instead, the Examiner merely makes conclusory statements regarding the Java 
programming language, class, JAR files and bytecodes (which clearly cannot be 
considered either a schema nor expressed in a data representation language). 
Furthermore, as is well known in the art, JAVA interfaces do not include schemas 
expressed in a data representation language. 

Thus, the rejection of claim 4 is not supported by the cited art and removal thereof 
is respectfully requested. Similar remarks also apply to claim 14 and 24. 
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Regarding claim 5, Beck fails to disclose where the first message is expressed 
in a data representation language . The Examiner cites column 5, lines 54-61 and 
column 6, lines 30-39. The cited portions of Beck describe that once a client has bound a 
service it can use that service by calling a method provided by the service's interface and 
that the service interface forwards the call to the service implementation that performs the 
requested service. Beck also teaches that the service interface and the service 
implementation are Java-based and that the RMI, OSF-RPC and HOP inter-process 
communication protocols are used. Beck does not mention anything about a message 
expressed in a data representation language and clearly fails to disclose wherein a 
message send by a client to the service is expressed in a data representation language. 
The Examiner is clearly speculating (which is improper) regarding the details of Beck's 
messages. As Beck makes no mention of any message expressed in a data representation 
language, Beck does not anticipate claim 5. 

In the Response to Arguments section of the Examiner's answer, the Examiner 
argues that Beck's Java Interface discloses messages expressed in a data representation 
language. However, as discussed above regarding claim 4, the Examiner's interpretation 
of Beck is incorrect. Please refer to the remarks above regarding claim 4 regarding the 
fact that a Java interface does not include or disclose anything expressed in a data 
representation language. 

The rejection of claim 5 is not supported by the cited art and removal thereof is 
respectfully requested. Similar remarks also apply to claims 15 and 25. 

Regarding claim 10, Beck fails to disclose the client using the URI and the 
schema in the advertisement to construct a gate for access to the service . The 

Examiner cites column 7, lines 34 - 44 of Beck. However, this passage of Beck does not 
describe a client using the URI and the schema in the advertisement to construct a gate 
for access to the service. First of all, as noted above regarding the rejection of claim 1, 
Beck fails to disclose a client reading an advertisement that comprises a schema that 
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specifies messages usable to invoke functions of the service. Secondly, nowhere does 
Beck describe the client using a schema from an advertisement to construct a gate for 
access to the service. Instead, Beck teaches that the service registry downloads the 
service interface, adapter and implementation and returns a reference to the client and 
that the client calls methods provided in the service's interface that forwards the call to 
the service adapter (Beck, column 6, lines 3-24 and lines 29-44). Beck fails to describe a 
client using the URI and the schema in the advertisement to construct a gate for access to 
the service. 

In the Response to Arguments section of the Examiner's Answer, the Examiner 
again cites column 7, lines 34 - 44 where Beck describes a service implementation that 
split into an implementation proxy and a remote service implementation. As noted 
above, the cited passage makes no mention of a client using the URI and the schema in 
the advertisement to construct a gate for access to the service. The Examiner is 
improperly ignoring the specific limitations of claim 10. Specifically, the Examiner is 
ignoring the fact that claim 10 recites, in part, a "client using the URI and the schema in 
the advertisement to construct a gate for access to the service" (emphasis added). The 
Examiner has not cited any portion of Beck, nor provided any other evidence or 
interpretation in support for the contention that Beck's client uses a schema in the 
advertisement to construct a gate to access the service. The Examiner argues that by 
downloading a service interface, Beck client is somehow using a URI and a schema from 
an advertisement to construct a gate for access to the service. However, as noted above, 
Beck's service interface cannot be considered "a schema" and is clearly not included in 
the service descriptor, which the Examiner equates to the Advertisement of Applicants' 
claims." 

Therefore, the rejection of claim 10 is not supported by the cited art and removal 
thereof is respectfully requested. Similar remarks apply to claims 20 and 30. 
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Section 103(a) Rejection : 



The Examiner rejected claims 6, 16 and 26 under 35 U.S.C. § 103(a) as being 
unpatentable over Beck in view of Official Notice. Applicants respectfully traverse the 
rejection of claims 6, 16 and 26 for at least the reasons presented above regarding their 
respective independent claims. 

The Examiner has failed to provide a proper motivation for combining the 
teachings of Beck with XML (based on Office Notice) to result in the specific limitations 
recited in claims 6, 16 and 26. The Examiner merely states, "[s]ince the combination of 
Beck and Official Notice discloses all of the above limitations, claims 6, 16, and 26 are 
rejected." However, obviousness cannot be established by combining or modifying the 
teachings of the prior art to produce the claimed invention, absent some teaching or 
suggestion or incentive to do so. In re Bond, 910 F. 2d 81, 834, 15 USPQ2d 1566, 1568 
(Fed. Cir. 1990). In addition, the showing of a suggestion, teaching, or motivation to 
combine prior teachings "must be clear and particular .... Broad conclusory statements 
regarding the teaching of multiple references, standing alone, are not 'evidence'." In re 
Dembiczak, 175 F.3d 994, 50 USPQ2d 1614 (Fed. Cir. 1999). The art must fairly teach 
or suggest to one to make the specific combination as claimed. That one achieves an 
improved result by making such a combination is no more than hindsight without an 
initial suggestion to make the combination. 

In the Response to Arguments section of the Examiner's Answer, the Examiner 
merely repeats the previous citations and asserts, "it is maintained that the stated 
motivation in the above rejection is sufficient" without actually rebutting any of 
Applicants' arguments above. The Examiner's statement that the combination of Beck 
and Official Notice "satisfies the need for a more efficient approach to service discovery 
that uses more efficient methods of describing and loading services" does not provide any 
motivation to modify Beck. Beck's entire invention is directed toward service discovery. 
Thus, one seeking an approach to service discovery would simply use Beck's invention, 
not modify it, as the Examiner contends. 
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Furthermore, Beck describes a specific Java interface for the service that a 
"defines the set of operations that the service can perform on behalf of a client" (Beck, 
column 5, lines 42-43). To modify Beck to use XML messages would be counter to the 
intended operation of Beck to employ a specific Java interface. If a proposed 
modification would render the prior art feature unsatisfactory for its intended purpose, 
then there is no suggestion or motivation to make the proposed modification. In re 
Gordon, 733 F.2d 900 (Fed. Cir. 1984). Accordingly, it would be improper to modify 
Beck's teachings to employ XML messages. 

The Examiner, in the Response to Arguments section of the Examiner's Answer, 
asserts, "Beck specifically offers language independence in his system to allow the data 
transfer and other possible service implementations to be written in any programming 
language." However, the fact that Beck teaches that service implementation may be 
written in any programming language actually supports Applicants' argument. As is well 
understood in the art, XML is not a programming language. Furthermore, modifying the 
programming language in which Beck's service implementation is developed does not 
provide any motivation to express a message specified in a schema in a data 
representation language that includes XML, as in Applicants' claim. 

The rejection of claims 6, 16 and 26 is not supported by the prior art and removal 
thereof is respectfully requested. 

Regarding both the § 102 and § 103 rejections above, Applicants also assert that 
numerous ones of the dependent claims recite further distinctions over the cited art. 
However, since the rejection has been shown to be unsupported for the independent 
claims, a further discussion of the dependent claims is not necessary at this time. 
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CONCLUSION 



Applicants submit the application is in condition for allowance, and prompt notice 
to that effect is respectfully requested. 

If any extension of time (under 37 C.F.R. § 1.136) is necessary to prevent the 
above-referenced application from becoming abandoned, Applicants hereby petition for 
such an extension. If any fees are due, the Commissioner is authorized to charge said 
fees to Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. Deposit Account No. 
501505/5181-64900/RCK. 

Also enclosed herewith are the following items: 
P<3 Return Receipt Postcard 
|~| Petition for Extension of Time 
[~1 Notice of Change of Address 
□ Other: 



Meyertons, Hood, Kivlin, Kowert, & Goetzel, P.C. 

P.O. Box 398 

Austin, TX 78767-0398 

Phone: (512) 853-8800 

Date: July 31. 2006 
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Respectfully submitted, 




Robert C. Kowert 
Reg. No. 39,255 

ATTORNEY FOR APPLICANT(S) 



